Sommaire : |
Introduction Architecture globale du Relais de Trames Trame FR et Circuits virtuels Contrôle de Congestion |
A l'origine conçu pour le RNIS (Réseau Numérique à Intégration de Services, en anglais ISDN), le relais de trame (en anglais Frame Relay ; on dit aussi, en français, "relayage de trames") est une amélioration notable de X25 (X25 a donné lieu aux premiers réseaux numériques comme Transpac en France).
Le relais de trame ne concerne que les couches basses du modèle OSI : couche physique (1) et couche liaison (2) . Il est bien adapté aux classes de réseaux fiables (c'est à dire avec un taux d'erreur faible) car des "économies" sont faites sur le contrôle d'erreur. Les débits atteignent 2 Mbits/s et peuvent aller jusqu'à 45 Mbits/s (Transpac atteignait 48 000 bits/s).
Avant d'exposer en quoi consiste le relais de trame, il est bon de faire quelques rappels sur X25. La commutation de paquets X25 est basé sur trois avis : X25 paquet pour la couche réseau, HDLC pour la couche liaison et X11 pour la couche physique. Le multiplexage des paquets est effectué par la couche réseau.
Les deux couches, liaison (pour les trames) et réseau (pour les paquets) effectuent un contrôle d'erreur et un contrôle de flux ce qui génère un trafic important. Imaginons par exemple le transport d'un paquet unique depuis un ordinateur émetteur vers un ordinateur récepteur en supposant que le réseau utilisé est basé sur X25 et se compose de 5 tronçons (liaisons) et de 4 noeuds de communication. La paquet sera transmis au récepteur qui, après vérification du champ de contrôle d'erreur, renverra un acquittement (en supposant qu'il n'y ait pas d'erreur). Toutefois, le paquet est encapsulé dans des trames au niveau de chaque liaison, et pour chaque trame un contrôle d'erreur est effectué (on suppose qu'il n'y a qu'une seule trame) avec retour d'acquittement. L'animation ci-dessous explicite le trafic généré par l'envoi de ce simple paquet et de son acquittement.
On constate que pour ce seul envoi, il est nécessaire de faire 20 transactions.
Architecture globale du relais de trames
Dans le cas du relais de trames, la couche liaison est séparée en deux sous-couches :
la sous-couche supérieure (couche d'adaptation ou LAPF control - LAPF = Link Access Procedure for Frame-mode bearer services, qui est une amélioration de LAPD) ne concerne que les éléments terminaux et non pas les noeuds du réseau : elle assure les fonctionnalités de contrôle de flux, de contrôle d'erreurs et d'acquittement. On l'appelle quelquefois la sous-couche EOP (Element Of Procedure).
la sous-couche inférieure (appelée noyau ou LAPF core) a pour fonctionnalités essentielles la commutation des trames, la détection des erreurs (mais pas leur traitement qui est du ressort de la sous couche adaptation ou des couches supérieures), l'indication de congestion, le multiplexage des trames. Les trames non valides sont simplement éliminées.
La couche physique n'est concernée que par la signalisation relative au "drapeau" de trame. Rappelons qu'une trame HDLC est délimitée par des drapeaux dont le code est "01111110". La couche physique remplacera systématiquement toute suite de "11111" par "111110" pour éviter de confondre un morceau d'information avec un drapeau.
On peut constater sur l'animation ci-dessous que le transfert de données en Relais de Trames est plus simple que dans le cas de X25 (on se place dans les mêmes conditions que l'animation précédente) :
La trame employée est analogue à celle de HDLC avec cependant les différences suivantes :
Il n'y a qu'un seul type de trame, la trame d'information ; il n'y a pas de trames de supervision, ni de trame non numérotées. La connexion et la déconnexion sont effectuées sur un canal spécial (le DLCI 0).
Il n'est pas possible d'effectuer des contrôles de flux, ni des traitements d'erreurs : pas de champs de numéro de séquence.
Le fanion ou drapeau est
la suite binaire "01111110".
Le champ en-tête peut prendre 2 (comme sur la figure ci-dessus) , 3 ou 4 octets ; il
contient essentiellement le numéro de DLCI (Digital Link Connection Identifier), c'est à
dire le numéro local du circuit virtuel emprunté (n'a de sens que sur une liaison).
Les champs FECN, BECN et DE sont explicités plus loin.
FCS (Frame Check Sequence) sert à la détection (uniquement) des erreurs. Si une erreur
est détectée, la trame est éliminée par le noeud concerné.
Le champ de données est variable, sa taille maximale est définie par la taille maximale
de la trame FR : 4 Ko.
DLCI tient sur deux blocs de bits, le premier de 6, le second de 4, ce qui fait 10 bits en tout ; les valeurs de DLCI peuvent donc aller théoriquement de 0 à 1023 ce qui correspond à des numéros de liaisons virtuelles. En fait, il existe des numéros réservés (par exemple, 0 est réservé à la demande de connexion, 1023 est réservé à la signalisation de congestion, ....) et il n'est possible d'utiliser que 992 numéros.
DLCI | Utilisation |
0 | signalisation (appel) |
1 à 15 | réservés |
16 à 1007 | DLCI pour utilisateurs |
1008 à 1018 | réservés |
1019 à 1022 | Multicast |
1023 | signalisation de la congestion |
Au passage à un noeud de communication, une table d'acheminement établit la connexion entre la liaison virtuelle entrante et la liaison virtuelle sortante ; ces tables d'acheminement sont mises à jour à chaque demande de connexion.
Le suivi du trafic et le contrôle de congestion est basé sur l'autodiscipline des utilisateurs. Chaque utilisateur souscrit un contrat pour un débit donné, le CIR (Committed Information Rate) ; le débit effectif est mesuré pendant une certaine période T et le CIR correspond au nombre de bits Bc (Committed Burst Size):
CIR = Bc/T
Il est toutefois permis aux utilisateurs de dépasser d'une certaine quantité ce débit, ou, pour raisonner sur la période T, la quantité Bc. On désigne par Be (Excess Burst Size) le surplus de bits permis ; le débit maximal autorisé est alors :
Dmax = (Be + Bc)/T
Le suivi du trafic, pour un utilisateur donné, est effectué par le noeud d'entrée. Ce suivi utilise le bit DE (Discard Eligibility) de la trame. On mesure pendant la période T, le nombre cumulé de bits émis. Trois cas sont à considérer :
La figure ci-dessous décrit l'envoi successif de trames d'un usager.
En cas de congestion, il est utile d'avertir les utilisateurs, ce qui peut se faire de trois manières différentes :